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Carl  Ebeling  and  Neil  McKenzie 
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Abstract 

We  descnbe  a  low-cost,  functional  tester  for  the  Macll  that  allows  students  to  test  and 
debug  digital  systems  Interactively.  This  tester  provides  a  large  number  of 
programmable  I/O  signals  and  can  be  used  to  test  chips,  boards  and  subsystems.  Test 
programs  are  easily  written  using  a  simple,  intuitive  interface  and  we  expect  a  variety 
of  interactive  graphical  testing  and  debugging  environments  to  be  built  for  the  tester. 
We  plan  to  make  this  tester  generally  available  in  kit  form. 


Introduction 

Testing  design  projects  in  the  University  is  typically  done  in  an  ad  hoc  way.  Some  sort 
of  hardware  environment  is  designed  around  the  project  to  create  a  self-contained 
system  which  can  be  operated,  observed  and  debugged  using  a  logic  analyzer  or 
oscilloscope.  Testing  and  debugging  a  partially  completed  system  or  a  subsystem  that 
operates  in  a  complex  environment  can  be  very  dilTicult.  As  the  complexity  of  projects 
grows  with  the  complexity  of  off-the-shelf  parts  and  the  capability  of  design  tools,  the 
problem  of  testing  Is  becoming  even  more  difficult.  This  is  especially  true  for  custom 
VXSI  chip  designs.  /Mthough  commercial  testers  provide  the  necessary  functionality, 
iheir  cost  is  prohibitive  and  the  usual  testing  environment  is  primitive. 

The  goal  of  the  MacTester  project  is  to  remedy  this  situation  by  providing  a  powerful, 
interactive  environment  for  functionally  testing  digital  systems.  Functional  testing 
means  that  the  values  and  sequencing  of  the  I/O  signals  can  be  verified  but  that  precise 
liming  cannot.  In  particular,  a  functional  tester  cannot  be  used  to  determine  how  fast  a 
system  can  run.  While  speed  testing  Is  clearly  Important,  testing  and  debugging 
concerns  tend  to  dominate  in  the  classroom  laboratory  situation.  We  believe  that  the 
issues  of  functional  testing  and  debugging  can  be  separated  from  those  of  timing 
validation. 

There  are  three  styles  of  testing;  OUline.  online  and  interactive.  The  usual  method  is 
offline  testing  where  a  list  of  test  vectors  is  prepared  and  presented  offline  to  the  device 
under  test  (DUT).  The  resulting  responses  are  collected  and  analyzed  after  the  test  is 
completed.  Online  testing  is  performed  in  real  time  where  each  test  vector  is  generated 
and  the  response  analyzed  before  succeeding  test  vectors  are  generated.  Interactive 
testing  allows  the  user  to  Interact  with  the  DUT  on  a  vector  by  vector  basis.  The  user  can 
inspect  the  results  of  the  current  test  vector  to  determine  the  next  vector.  Efficient 
debugging  is  facilitated  by  a  good  interactive  testing  environment.  The  onlv  drawback 
to  Interactive  testing  is  that  it  cannot  be  used  for  circuits  with  dynamic  state. 
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The  MacTester  has  been  designed  to  allow  all  three  ty^pes  of  testing,  although  we  view 
interactive  testing  and  debugging  as  the  most  important.  The  Macintosh  computer  is  an 
ideal  host  for  interactive  testing  and  debugging  because  of  its  uniform,  intuitive  user 
interlace  and  Interactive  graphics  capability.  The  tester  and  the  software  interface 
provide  the  mechanism  with  which  a  wide  variety  of  testing  environments  can  be  built. 
We  e.\pect  many  different  graphical  and  procedural  interfaces  to  the  tester  to  be  built  as 
users  define  their  own  tesUng  needs. 

Cost  and  functionality  were  often  competing  goals  in  the  design  of  the  MacTester.  We 
decided  to  provide  the  following  features  that  we  felt  were  necessary  for  a  tester  used  in 
design  laboratories: 

•  The  tester  is  easily  shared  by  more  than  one  project.  Changing  the  test  setup  from  one 
project  to  another  takes  only  the  few  minutes  needed  to  change  the  power  and  ground 
jumpers.  tA.  pre-test  can  be  performed  to  ensure  that  the  power  and  ground  setup 
matches  the  specification.)  This  ability  to  share  reduces  the  number  of  testers  that  are 
needed  and  the  overall  cost. 

•  Tlie  tester  provades  a  large  number  (128)  of  test  signals  so  that  even  large  projects  can 
oe  accommodated. 

•  .Ml  signals  are  bi-directional  and  can  be  individually  set  to  the  input  or  output  state. 
Mthough  this  makes  the  tester  implementation  more  expensive,  it  facilitates  sharing 
between  projects  since  all  pins  can  be  redefined  in  software.  Moreover,  smce  the 
direction  can  be  set  dvmamically.  tri-state  busses  can  be  tested. 

•  Provision  has  been  made  for  dynamic  circuits  by  including  an  on-b.'iard  memory 
capable  of  storing  several  thousand  test  vectors.  The  tester  can  lndepei*dently  present 
these  vectors  at  a  rate  of  1  MHz.  Mthough  dynamic  circuits  cannot  be  tested  in  a  truly 
interactive  fashion,  the  tester  software  includes  a  construct  that  allows  the  user  to 
maintain  the  illusion. 

We  will  begin  by  descnbing  the  software  interface  to  the  tester  to  show  how  the  user 
views  the  devace  under  test.  We  then  outline  the  implementation  of  the  hardware  and 
the  software. 

The  Tester  interlace 

In  this  section,  we  describe  how  the  device  under  test  (DUT)  appears  from  the  point  of 
view  of  a  test  program  and  how  the  program  manipulates  the  I/O  signals.  The  tester 
software  provides  a  simple,  intuitive  interface  that  makes  it  easy  for  programs  to  use 
the  tester.  These  programs  can  range  from  simple  test  programs  devised  by  the  user  to 
sophisticated  interactive  programs  that  supply  a  visual  Interface  via  schematics  and 
timing  diagrams.  A  simple  test  program  for  a  combinational  multiplier  is  shown  in 
Figure  1. 

To  the  user,  the  pins  of  the  DUT  appear  as  variables  in  the  test  program.  The  user  first 
defines  a  set  of  signal  variables  in  the  Def  ineSignais  section,  each  as  a  collection  of 
pins,  and  then  manipulates  the  values  of  the  pins  via  these  variables.  Changing  the 
value  of  a  signal  variable  changes  the  values  of  the  associated  pins  and  reading  the 
value  of  a  signal  variable  reads  the  values  of  the  pins.  Although  most  signal  variables 
are  declared  as  input  or  output  variables,  they  can  also  be  declared  to  be  bi-directional 
and  the  direction  changed  at  any  time. 

A  test  proceeds  as  a  series  of  test  steps,  each  activated  by  the  Next  control  statement.  In 
each  test  step,  a  new  set  of  values  is  first  driven  in  unison  onto  the  DUT  Input  pins  and 


then  the  resulilng  values  of  the  DUT  output  pins  are  latched.  These  events  are  separated 
by  enough  tln.e  to  allo’.v  the  output  values  to  become  stable  before  they  are  sensed.  In 
fact,  the  tester  provides  a  very  limited  version  of  speed  testing  by  allowing  the  user  to  set 
this  time  interval.  The  delay  from  the  clock  driving  the  input  values  to  the  clock 
latching  the  output  values  can  be  preset  to  any  value  from  20  ns.  to  1  psec.  in  increments 
of  about  5  ns. 

'  *  Define  the  chip  signals  *  < 

Def  ir.eSigr.ais 

Signal (Multiplier,  "2,4,6,8,10,12,14,16”,  INPUT,  0); 

Signal (Multiplicand,  "3,5,7,9,11,13,15,17",  INPUT,  0 )  ; 

Signal (Result,  "25:18”,  OUTPUT); 

SndSignals 

iTiain  ( ) 

f 

aeginTest ; 

for  (i=0;  i<256;  i++)  i 
for  (j=0;  j<256;  ir+)  ( 

SetSignal (Multiplier,  i); 

SetSignax (MuJ ttpiicana,  h ; 

■Next  ; 

if  (GetSignai (Resuit )  '=  i’:)  I 

printf  ("error :  Id  *  d  ==>  *d\n",  i,  j,  Getsignal  (Result)); 


EndTest ; 


Figure  1:  Test  program  for  a  combinational  multiplier. 

The  values  of  signals  are  changed  via  die  setsignai  statement,  and  the  values  accessed 
via  the  GetSignai  statement.  SetSignal  statements  do  not  take  effect  immediately, 
but  the  values  specified  are  collected  and  applied  to  the  pins  of  the  DUT  by  the  Next 
sequencing  statement,  which  performs  all  accumulated  changes  in  parallel.  The 
letSignai  Statement  returns  the  value  of  the  signal  latched  by  the  most  recent  Next 
statement.  Thus  a  step  in  the  test  program  typically  consists  of  a  set  of  SetSignal 
statements  followed  by  a  Next  statement  followed  by  a  set  of  GetSignai  statements. 

The  direction  of  a  sgnal  declared  in  the  DefineSignai  statement  can  be  input,  output. 
or  BIDIRECTIONAL.  The  direction  of  bi-directional  sgnals  can  be  changed  at  any  time 
via  the  SetDirection  statement.  These  changes  are  accumulated  like  sgnal  value 
changes  and  applied  by  the  next  Next  statement. 

Each  test  step  can  be  thought  of  as  a  test  vector,  except  that  each  test  vector  is  created  on 
the  fly  by  the  program  and  the  resulting  response  is  available  immediately  and  can  be 
used  to  generate  the  next  test  vector.  This  makes  testing  truly  interactive  from  the  point 
of  view  of  the  test  program  and  this  view  can  be  passed  along  to  the  user. 

The  tester  provides  no  signals  other  than  those  provided  by  the  user  program.  In 
particular,  the  test  prognim  must  supply  the  clocks  by  changing  a  signal  variable  or  set 
of  variables  explicitly.  Thus  a  single  clock  cycle  for  a  circuit  using  a  two-phase  non- 
overlapping  clock  requires  at  least  four  test  vectors.  Figure  2  gives  a  test  program  for  a 
single-stage  pipelined  multiplier. 


*  Define  the  chip  signals  "/ 

3ef ineSignais 

iignai (Multiplier ,  ""  :  , 6 , 8 , 1 0 , 12 , 1 4 , 1 6" ,  INPUT,  1); 

Signal (Multiplicand,  .5,7,9,11,13,15,17",  INPUT,  S ) ; 
Signal (Resu-t ,  "25:1  OUTPUT); 

Signal  (Phil.  '26",  INT-'T,  1 )  ; 

Signal  (Phi2.  '27",  i;;;-  r,  2); 

E.-idSignals 

Sloc)<Chip()  ■  Perform  a  single  Phil/Phi2  clock  cycle  ”  ' 

Next;  ,/ *  Assert  data  before  clocking  ’  ' 

Set Signal ( Phi 1 ,  S ) ;  Next; 

SetSignai ( ?hi2 ,  1);  Next; 

SetSignai (Phi2,  0);  Next; 

SetSignai  {  Phil ,  1);  Next; 

otatic  int  iastX,  lastY,  lastResult;  ,  *  Previous  test  ’ ^ 

init'  ultl)  *  Fill  the  pipeline  ’ 


..etSicna.  ;Mul  tiplier ,  I'; 

SetSignai (Mult iplicana,  '); 

SlocxChip ( ) ; 

lastResult  -  .astX  =  lastY  =  1; 

'  estrtult  (:•:,  y)  *  Perform  one  test  of  the  multiplier  ’ 
int  y; 


SetSignai  (Multiplier,  ;■;)  ; 

SetSignai (Multiplicand,  y)  ; 

ClocxChip ( ) ; 

if  (GetSign.-- (Result)  '=  lastResult)  • 

printf  ( "~rrcr :  x  *  •;<  =>  ';<[i,xi\n",  lastX,  lastY, 
SetSicrnal  (Pesult)  ,  lastResult)  ; 


lastResult  =  *  v; 

-  a  s  t  X  = 

-  a  s  t  Y  =  y  ; 

•T.a  1  n  ( ) 

BeginTest ; 

initf.ult ;  /*  Fill  pipeline 

for  (1  =  0;  i<256;  i--^)  { 

for  (j=0;  j<256;  :++)  j 
testmult ( i ,  ■ ;  ; 


testmult(0,  S);  i*  Flush  pipeline  ' ' 

EndTest ; 


Figure  2:  Test  program  for  a  single-stage  pipelined  multiplier. 


Dynamic  and  Pseudo-atatic  Circuits 

Dynamic  circuits  cannot  be  tested  Interactively  because  the  dynamic  state  is  lost  unless 
the  circuit  Is  operated  continuously.  Since  the  time  for  which  dynamic  state  can  be  held 
is  typically  much  less  than  a  second,  user  interaction  is  not  possible.  Online  testing 
may  also  be  ruled  out  if  the  time  between  test  vectors  cannot  be  bounded.  In  particular, 
programs  running  under  A/UX  can  be  interrupted  by  the  operating  system  for  relatively 
long  periods  of  time. 

The  MacTester  accommodates  dynamic  circuits  via  onboard  test  vector  memory  which 
permits  offline  testing.  In  online  mode,  the  Next  statement  causes  accumulated  values 
to  be  written  directly  to  the  DUT  pins  and  the  response  to  be  read  back.  In  offline  mode, 
the  test  vectors  generated  by  the  Next  statement  are  stored  in  test  vector  memory  and 
presented  all  at  once.  Independently  from  the  test  program.  The  responses  are 
accumulated  in  the  test  vector  memory  and  can  be  read  back  after  the  offline  test  has 
completed. 

testmuit (x,  y)  *  Perform  cne  cesc  of  the  multipJ ier  ' ' 


oetSicnax  (Multiplier,  :<)  ; 

SetSlanal  (.Multiplicand,  y)  ; 
llocxChip  ( )  ; 

Verify 

if  (GetSignal (Result)  !=  lastResult)  i 
printf ( "Error :  sx  *  %x  =>  %x[%x]\n", 

lastX,  lastY,  GetSignal (Result )  ,  lastResult ) ; 

i 

EndVerify 

lastResult  =  :<  *  y; 
lastX  =  x; 
lastY  =  y; 

T.a  1  n  ( ) 

ReginTest ; 

for  (1  =  0;  i‘-256;  l*-^)  • 

3eginDynamic ; 

initmult 0 ;  /*  Fill  pipeline 

for  (j=0;  ]<256;  i 

testmult ( i  ,  3 )  ; 

testmultiO,  0);  /*  Flush  pipeline  */ 

EndDyna.mic; 


EndTest ; 


Figure  3:  Tfie  modified  test  program  for  a  dynamic  one-stage,  pipelined  multiplier. 


The  tester  software  package  contains  a  ckinamic  block  construct  that  is  used  to 
maintain  the  illusion  mat  the  test  program  Is  online  when  in  fact  it  is  not.  A  dynamic 
block  is  created  by  wr  -..ning  an  arbitrary  set  of  statements  with 

3eginDynaitu.c/EndDyr.arr.Lc:  statements.  A  dynamic  block  is  executed  twice.  In  the  first. 
generate,  phase,  all  the  '  vectors  c  r-.crated  within  the  block  are  accumulated  and 

presented  offline  when  u  nd  of  the  .r.-namic  block  is  encountered.  In  the  second. 

verify,  phase,  the  respons.  vectors  are  available  in  the  right  sequence  and  statements 
that  access  these  are  executed. 

Clearly  this  places  restrictions  on  the  program  statements  In  the  dynamic  block  since 
some  should  be  executed  only  in  the  first  phase,  and  others  only  in  the  second  phase. 

The  SetSignai  statement  is  defined  to  have  effect  only  in  the  generate  phase  -  other 
statements  that  are  to  be  restricted  to  the  generate  phase  can  be  protected  usmg  the 
Generate  macro.  The  Verify  macro  Is  used  to  protect  statements  that  are  executed  only 
in  the  verify  phase. 

The  test  program  in  Figure  2  can  be  changed  to  test  a  completely  dynamic  pipelined 
multiplier  as  shown  in  Figure  3.  The  dynamic  block  has  been  placed  as  shown  because 
:he  test  vector  memory  Is  limited  to  about  5300  vectors.  N'ote  that  U  the  '.'►-'ri  fy 
protection  macro  is  left  out.  the  program  will  produce  errors  durmg  the  cenerate  phase 
because  the  result  of  GecSrgnai  is  undefined  during  this  phase. 

Dynamic  circuits  n  certainh-  make  test  programs  more  complicated.  Fortunately, 
most  dynamic  circ  ats  can  sur  ive  online  testing  since  11'  the  computation  required  to 
generate  each  test  vector  is  limited,  online  testing  can  proceed  at  about  50  KHz.  Tliis  is 
true  for  programs  under  .MacOS.  but  we  were  pleasantly  surprised  to  find  that  test 
programs  running  under  A/UX  generally  worked  as  well. 

Fseudo-siauc  cacuii.o,  dial  is.  ciicuiis  that  aie  static  at  Some  pomt  in  the  clock  cycle, 
can  be  tested  interactively.  In  this  case,  the  dynamic  block  is  limited  to  a  few 
statements  and  the  test  program  can  be  interactive  at  the  granularity  of  a  clock  cycle 
rather  than  each  test  vector.  For  example,  li  the  multiplier  in  Figure  3  were  pseudo¬ 
static,  the  dynamic  block  would  be  confined  to  the  ClcdcC.hip  procedure. 


Implementation 

.\  very  high-level  block  diagram  of  the  tester  is  shown  in  Figure  4  During  one  step  of  an 
online  lest,  the  appropriate  level  1  registers  are  first  written  by  the  host.  These  values 
are  then  transferred  in  unison  to  the  level  2  registers  which  are  connected  directly  to 
the  DUT  pins.  The  level  3  registers  are  then  latched  after  some  user-specil'ied  delav. 
Finally,  the  results  in  the  level  3  registers  are  read  back  by  the  host. 

Offline  testing  is  performed  by  first  downloading  the  test  vectors  into  the  test  vector 
memory  and  Indicating  the  stan  and  end  address  of  the  sequence.  Tlie  tester  then 
performs  the  offline  lest  by  transferring  test  vectors  to  the  level  1  registers  and  results 
from  the  level  3  registers  back  Into  test  vector  memory.  When  the  end  address  is 
encountered,  a  done  bit  Is  set  in  the  interlace  control  register  and  the  host  can  upload 
the  responses.  The  olfline  test  can  also  be  placed  in  a  loop  so  that  a  particular  test 
sequence  can  be  monitored  with  an  oscilloscope. 

The  hardware  design  was  simplified  by  the  use  of  Xillnx  programmable  gale  array 
chips.  The  data  path  is  implemented  in  six  XC3020  chips  and  the  control  lot’*''  m  a 
seventh  /Mthough  the  Implementation  would  have  been  possible  using  fewer  of  the 
larger  Xillnx  gate  arrays,  the  cost  per  pin  grows  almost  quadratically,  and  the  XC3020 
was  chosen  as  the  most  cost-effective  size.  The  choice  of  XUlnx  gate  arrays  allows  the 
data  path  and  control  to  be  changed  by  the  user  via  the  Xillnx  design  software.  For 


example,  the  programmable  delay  was  implemented  after  the  fact  by  using  a 
multiplexor  to  speedy  the  number  of  logic  levels  between  the  drive  and  latch  clocks. 


Data  Bus 


Figure  4:  The  overall  block  diagram  of  the  tester.  The  data  path  is  1 28  bits  deep. 

The  test  vector  memory  is  potentially  a  large  and  expensive  pan  of  the  tester.  We  chose 
to  trade  cost  for  speed  by  multiplexing  the  RAM  six  ways.  This  reduces  oifline  testing 
rate  from  a  possible  5MHz  to  IMHz.  but  reduces  the  number  of  static  RAM's  from  48  to  8 
ind  reduces  the  number  of  I/O  pins  required  for  the  datapath. 

The  tester  is  Implemented  as  an  8x13  inch  PC  board  as  shown  in  Figure  5.  This  board  is 
connected  via  a  simple  parallel  Interlace  to  an  ADDEIX  NuBus  interlace  board  that  plugs 
directly  into  the  MaclI.  This  interface  is  quuc  simple  end  interfacing  the  tester  to  other 
busses  like  the  SBUS  or  VME  bus  is  straightforward. 


Software  Interface  Implementation 

At  the  lowest  level,  the  tester  control  and  data  registers  are  mapped  directly  into  the 
address  space  of  the  user  program.  This  is  possible  for  both  MacOS  and  A/UX  programs 
and  greatly  simplifies  the  interface  implementation.  At  the  lowest  level,  a  set  of 
macros  is  provided  for  accessing  these  registers  and  for  performing  all  the  tester 
control  operations.  In  addition,  memory  Is  allocated  for  collecting  signal  values  and 
directions  for  each  signal  variable  defined. 

At  the  next  level,  user-visible  operations  are  implemented  using  the  low-level  macros 
and  interface  memory.  The  SetSignai.  SetDirection  and  GetSignai  operations  are 
implemented  in  two  diflerent  ways  depending  on  when  the  signal  variables  are  defined. 
If  they  are  defined  dynauilcally.  then  these  eperaUons  must  be  Interpreted.  Otherwise 
they  can  be  pre -compiled  into  a  much  more  efficient  Implementation. 


Fi^tire  5:  Outline  of  the  tester  PC  board. 

There  is  a  wide  ran^e  of  possible  testiruJ  and  debusing  envtronmenis  lhai  can  be  built 
on  top  ol  the  MacTester.  First,  as  shown  in  the  sample  programs,  writing  test  programs 
is  straightforward,  in  fact,  a  program  is  a  very  powerful  way  to  spccifv'  the  beha\aor  oi 
the  environment  of  the  sv'stem  being  tested.  One  such  technique  is  to  write  a  procedure 
that  takes  an  abstract  operation  and  maps  It  Into  the  sequence  of  signal  values  that 
implements  that  operation.  F'or  e.xample.  il'  testing  a  dvnamic  IMM.  one  would  write 
pnxtedures  lor  the  read  and  write  operations  that  generates  the  multiplexed  address  and 
the  appropriate  R>\S/CAS.  .■\n  elfectlve  wav  to  familiarize  students  with  the  operation 
ii  the  more  cornple-x  oif-the-shelf  pans  is  bv  havmij  them  write  such  test  prourams 

\'''e  expect  a  variety  ol  graphical  testing  envaronments  to  be  developed  as  well.  !n  such 
in  envaronment.  the  inputs  and  outputs  of  the  device  being  tested  can  be  displayed  in 
'separate  windows  and  formatted  In  different  ways,  for  example  as  timing  diagrams  or  a 
time  line  of  values.  For  example.  Capllano  has  graphical  simulation  tools  which  can 
iritertace  to  other  software  using  what  Is  called  the  Meda  interlace.  Using  these  tools, 
the  tester  can  be  incorporated  Into  the  graphical  simulation  as  a  separate  device.  .\11 
the  graphical  I/O  devices  such  as  keypads,  displays,  and  timing  diagrams  that  are 
prov'ided  by  the  Capllano  simulation  tools  can  then  be  used  to  test  and  debug  one  s 
project  In  the  tester.  .Moreover,  the  project  can  be  simulated  as  part  ol  a  larger  system  as 
descnbed  by  schematic  drawings. 

We  also  plan  to  use  the  tester  in  the  RNL  simulation  environment.  RNL  provides  an 
interactive  Lisp  environment  for  testmg  MOS  circuits.  First,  the  simulation  can  be 
replaced  bv  the  tester  and  the  interactive  Lisp  environment  used  to  test  the  project. 
Second.  If  there  is  a  circuit  description  for  the  project,  then  the  same  program  used  tu 
test  the  design  can  be  used  to  test  the  Itnlshed  product.  .Moreover,  the  simulation  and 
the  tester  can  be  run  In  parallel  and  the  results  compared.  This  same  strategy  can  be 
used  for  other  simulators,  notablv  the  COSMOS  simulator. 


Status 


Hie  I-jU  12S  tesi  pin  PC  board  •version  has  been  completed  and  is  currently  beini>  used  to 
test  two  VXSI  chips  usin^  testprograms  and  the  simple  sottware  interlace.  The 
mtenace  to  the  Captlano  sollware  will  be  completed  this  summer,  as  well  as  RNL  and 
t'OS.MOS  Irontends.  Anyone  interested  in  obtalnm^  this  tester  should  contact  the 
authors.  We  are  currently  piannln^  to  make  the  tester  available  in  kit  form  alon^  with 
,1  set  of  test  software  for  the  llacll. 
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